In 3G Universal Mobile Telecommunications Systems (UMTS) and in particular in its evolved version System Architecture Evolution/Long Term Evolution (SAE/LTE), also referred to as Evolved Packet Core/Evolved Universal Terrestrial Radio Access Network (EPC/E-UTRAN), and also Evolved Packet System (EPS) although EPS also comprises the combinations EPC/UTRAN and EPC/GERAN, the concept of home base stations is introduced. GERAN is an abbreviation for GSM EDGE Radio Access Network, wherein GSM in turn is an abbreviation for Global System for Mobile communications and EDGE is an abbreviation for Enhanced Data rates for GSM Evolution. In 3G radio access (UTRAN) a home base station is referred to as a Home Node B (HNB) whereas in EPC/E-UTRAN it is referred to as a Home eNodeB (HeNB). A cell served by a HNB or a HeNB is commonly referred to as a femtocell. A home base station is assumed to be placed in a private home, utilizing the home owner's fixed broadband connection to access the core network. Other possible deployments are in a campus, shopping mall, company etc. It is also assumed that the home owner handles the actual physical installation of the home base station. Hence, the deployment of home base stations cannot be planned, since it is largely outside the control of the operator. Another important property of the home base station concept is the potentially large number of home base stations.
A HeNB/HNB provides normal service for the end users and is connected to the mobile core network using Internet Protocol (IP) based transmission, typically the HeNB/HNB owner's broadband access and the Internet. The radio coverage provided may be referred to as a femtocell. In a typical example deployment scenario, a femtocell covers the HeNB/HNB owner's home.
One of the main drivers of this concept of providing local access is to provide cheaper call or transaction rates/charges when connected via the HeNB/HNB than when connected via a eNodeB, i.e. an E-UTRAN base station; or a NodeB i.e. a UTRAN 3G WCDMA/HSPA base station. Another driver is reducing the load on the operator's eNodeBs/NodeBs and backhaul connections, thereby reducing the operator's Capital Expenditures (CAPEX) and Operational Expenditures (OPEX).
The term Home Node (HN) is here used as a common name for a 3G/UTRAN Home NodeB or an EPC/E-UTRAN Home eNodeB. A HN may connect to the operator's network via a secure tunnel, supposedly IPsec protected, to a security gateway at the border of the operator's network. Via this tunnel, said HN node connects to the core network nodes of the operator's core network, such as e.g. Mobility Management Entity (MME) and Serving Gateway (S-GW) via the S1 interface or Serving General Packet Radio Service (GPRS) Support Node (SGSN) and Mobile Switching Centre (MSC), or Media Gateway (MGW) and MSC server via the lu interface. lu is the interface between the radio access network and the core network in 3G UMTS, i.e. between Radio Network Controller (RNC), or a HNB via a HNB Gateway, and SGSN/MSC/MSC server/MGW, depending on the access technology used.
The 3rd Generation Partnership Project (3GPP) operator may also deploy a concentrator node in its network between the 3G/UTRAN Home NodeBs or, EPC/E-UTRAN Home eNodeBs and the regular core network nodes. In the EPC/E-UTRAN standardization such a concentrator node is commonly referred to as a HeNB Gateway, which may be an optional node in HeNB solutions. The corresponding node name in 3G UMTS standardization is HNB Gateway and this node is mandatory in 3G HNB systems.
A possible Network Address Translation/Translator (NAT) between the HN and the 3GPP network is not a problem for the IPsec tunnel, because Internet Key Exchange version 2 (IKEv2), which can handle NAT traversal, i.e. activate User Datagram Protocol (UDP) encapsulation for Encapsulating Security Payload (ESP) traffic as needed, is assumed to be used for the IPsec tunnel establishment. Internet Protocol Security (IPsec) is a suite of protocols for securing IP communications by authenticating and encrypting each IP packet of a data stream. IKEv2 and/or IPsec also comprise protocols for establishing mutual authentication between agents at the beginning of the session and negotiation of cryptographic keys to be used during the session. In the following descriptions and drawings, entities related to security, e.g. Security GateWay (SEGW) has been left out.
Through this setup a mobile node, which also may be referred to as e.g. a User Equipment (UE), communicates via the HN and the core network like any other mobile node.
When a HN is installed, the Operation and Maintenance (O&M) system directs the HN to connect to a suitable core network node or pool of core network nodes, via a concentrator node, i.e. a HeNB connects to an MME pool, probably via a HeNB Gateway, and a HNB connects to an SGSN and possibly an MSC or MSC server, or pools of such nodes, via a HNB Gateway. The suitable core network node or pool of core network nodes that the O&M system selects is the core network node, or pool of core network nodes which serves the macro layer base stations whose cells cover the location where the HN is located. The purpose of this choice of core network node, or pool of core network nodes is to as far as possible avoid inter-core network node handovers, e.g. inter MME pool handover or inter-SGSN/pool handover, when the mobile node is handed over between a macro layer base station and the HN or vice versa. The same principle applies also for idle mode mobility i.e. when a mobile node moves in idle mode between a macro layer base station and the HN or vice versa. In this case it may be beneficial to avoid inter-core network node registration area updates, i.e. Tracking Area Updates in EPC/E-UTRAN and Location Updates and Routing Area Updates in 3G to avoid the need to perform inter-core network node signalling and to avoid updating the mobile station's new location in the Home Location Register (HLR) and/or Home Subscriber Server (HSS).
The HN concept is closely related to the concept of subscriber groups such as e.g. Closed Subscriber Group (CSG). A femtocell may also be assumed to be a subscriber group cell such as e.g. a CSG cell. This means that only a selected group of subscribers are allowed to access the network through that cell. In the system information broadcast in a CSG cell a Boolean type CSG indication is included to inform mobile stations that the cell is a CSG cell. In addition, the subscriber group e.g. CSG of a subscriber group cell e.g. CSG cell is identified by a subscriber group identifier e.g. CSG ID, which may also be broadcasted in the cell as a part of the system information. Typically each subscriber group cell, e.g. CSG cell, has its own unique subscriber group identifier, such as e.g. CSG ID, but it may also be possible to define the same subscriber group identifier e.g. CSG ID for multiple cells, thereby forming a subscriber group zone, in which the same selected group of subscribers is allowed access. However, a subscriber group cell e.g. a CSG cell does not, in principle, have to be a femtocell, but may be also any other type of cell.
Hence, all subscribers are not allowed to access a certain HN and a certain subscriber is not allowed to access all HNs. Under supervision of the operator the owner of a HN defines which subscribers are allowed to access a femtocell and/or CSG cell of the HN, i.e. which subscribers that are included in the CSG of the femtocell. The created data is herein referred to as “CSG data”, “CSG definition” or possibly “HN access list”, which is an equivalent term assuming that the HN only serves one CSG, which may typically be the case. This is assumedly done through a web interface, or other “interface” between the HN owner and the operator's administrative systems, and the CSG data is stored in a database in the operator's network, which may be regarded as a part of the operator's Operation, Maintenance, Administration & Provisioning (OMA&P) system. Note that the entities interacting with the HN owner for this purpose may be entities devoted to subscriber administration/provisioning or entities devoted to O&M tasks and in this document also such entities are, for simplicity, grouped into what is known as the OMA&P system. A subscriber may be included in a CSG indefinitely, i.e. until explicitly removed, or on a time limited basis, often referred to as a “guest”. Although the exact mechanism and format are not specified in 3GPP yet, the HN owner may be assumed to enter the allowed subscribers in the form of Integrated Services Digital Network numbers (ISDN numbers), e.g. Mobile Subscriber ISDN number (MSISDN number), or International Mobile Subscriber Identities (IMSI).
The CSG data, or HN access list, is reflected in the so-called Allowed CSG Lists (ACL), also known as CSG Whitelists, associated with the concerned mobile nodes. Each mobile node has an Allowed CSG List, which includes the CSG ID of each CSG the mobile node, or more precisely the subscriber using the mobile node is included in, i.e. the CSG ID of each femtocell the mobile node or actually the subscriber is allowed to access. A CSG is actually associated with a group of subscribers rather than mobile nodes, but for simplicity the term mobile node may be used as the entity of which a CSG is formed. Similarly, a CSG Whitelist may actually be associated with a subscriber rather than with a mobile node, but for simplicity the mobile node in this context may be used as a “proxy” for the subscriber using it, such that a CSG Whitelist may be referred to as belonging to the mobile node and the mobile node may be said to be allowed or not allowed access to a CSG cell.
The ACL of a subscriber may be stored in a database e.g. the HSS of the subscriber's home network together with other subscriber data, but another database than the HSS may eventually be chosen for this task. The data is transferred from the OMA&P system, where the CSG data resides, to the HSS, where it is distributed to appropriate subscriber records. This applies to both creation and updates, i.e. additions or exclusions of subscribers of the CSG data. It is also possible for the OMA&P system to maintain its own copies of the ACLs or to assemble them from the CSG data when needed. The ACL of a subscriber may also be stored in the mobile node of the subscriber, e.g. in the Universal Subscriber Identity Module (USIM) so that the mobile node itself may determine whether it is allowed to access a certain CSG cell or not, in order to avoid useless access attempts. The ACL may be transferred from the network to the mobile node for example via Open Mobile Alliance Device Management (OMA DM), or Over-The-Air (OTA) USIM configuration technology, or Short Message Service (SMS) or implicitly via NAS signalling. Furthermore, in EPS/LTE the ACL of a mobile node may be downloaded from the HSS to the MME serving the mobile node, assumedly together with other subscriber data which is relevant for the serving MME, so that the MME may perform CSG based access control of mobile nodes requesting network access via a CSG cell, e.g. an Attach Request, a Tracking Area Update (TAU) Request or a Service Request. This mechanism is likely to be similar in 3G, utilizing a node corresponding to the MME, i.e. the SGSN and/or the MSC server, performing CSG based access control on the corresponding 3G procedures.
The search for allowed CSG cells is not governed by the network, but is left to the mobile node to handle autonomously. To identify an allowed CSG cell the mobile node must read the CSG ID from the system information broadcast in the cell and compare it with the CSG ID/s stored in ACL. When a match is found, the mobile node has discovered an allowed CSG cell.
During handover into a CSG cell the source (H)eNodeB, or source Radio Network Subsystem (RNS) or source HNB in 3G or source Base Station Subsystem (BSS) in 2G rely to a greater extent on the mobile node than during other handovers, because the neighbour relations are not maintained towards CSG cells in the same way as towards regular macrocells. Hence it is up to the mobile node to detect and report the presence of a CSG cell which may be a suitable target cell for handover. In addition, all handovers into a CSG cell are signalled via the core network e.g. S1 handover in EPC/E-UTRAN.
When a mobile node is handed over to a CSG cell, CSG based access control has to be performed, just as when a mobile node performs TAU, LAU or RAU or sends a service request in a CSG cell.
Currently, the only CSG based access control defined in the network, i.e. excluding the mobile node's own filtering of allowed and not allowed CSG cells, based on its internal ACL is the access control the serving MME or SGSN or MSC/MSC server performs when a mobile node accesses a CSG cell, e.g. Attach Request, Tracking Area Update (TAU)/Location Area Update (LAU)/Routing Area Update (RAU) Request or Service Request.
There is no CSG based access control mechanism designed/specified specifically for handover into a CSG cell. Moreover, applying the regular CSG based access control in the handover into CSG cell case has significant disadvantages.
First, in conjunction with handover into a CSG cell the regular CSG based access control will not be triggered until the mobile node performs a location registration, i.e. TAU in EPC/E-UTRAN, RAU/LAU in 3G, after the handover is concluded. This means that resources are allocated in the target CSG cell, resources are released in the source cell and the mobile node is already communicating in the target CSG cell when the access control is to be performed.
Second, a location registration e.g. TAU may not be triggered in all cases. If the handover is handled via a single Core Network Control Node (CNN), such as e.g. MME, and the mobile node, after moving to the target CSG cell, remains in a registration area e.g. Tracking Area or Routing Area, which does not trigger a location registration, there will be no location registration. Thus an illegitimate mobile node could access a non-allowed CSG cell via handover. As the intelligent femtocell deployment strategy aims at avoiding Inter Core Network Control Node Handovers, such as e.g. inter-MME handovers this may be a most likely case. The known CSG based access control in the serving Core Network Control Node, such as e.g. MME, may thus not be triggered in a handover scenario, under some circumstances.
Third, a malicious mobile node aiming at getting access through a non-allowed CSG cell may simply omit the trailing location registration, even though the circumstances would normally trigger it, in order to avoid the CSG based access control.
Thus new mechanisms for access control in conjunction with handover into a subscriber group cell are needed.